Nombreux sont ceux qui souhaitent diffuser les documents qu'ils ont créés au format QuarkXPress Passport™ sur Internet. Aussi, les façons de procéder sont multiples. La plus efficace, cependant, est de séparer le contenu des documents QuarkXPress Passport des documents eux-mêmes, puis de stocker ce contenu dans un format structuré tel que le langage XML. Vous pouvez alors réutiliser ce contenu sur Internet, mais aussi dans d'autres formats impression sur papier, CD-ROM, etc.
Le logiciel avenue.quark™ est conçu pour faciliter l'extraction de vos contenus QuarkXPress Passport et leur stockage au format XML.
Avenue.quark vous permet d'extraire le contenu de documents QuarkXPress Passport et de le stocker au format XML. Vous pouvez alors aisément réutiliser ce contenu de diverses façons, y compris sur Internet. Cette section présente brièvement le processus ainsi que des définitions ; des descriptions plus détaillées sont proposées dans les sections suivantes.
Qu'est-ce qu'un contenu ?
Le contenu définit les informations constituant la valeur de vos documents. Par exemple, le contenu d'un magazine comprend des articles, des photos, des interviews et des schémas.
Le contenu peut également être défini par ce qu'il n'est pas. Par exemple, les en-têtes, les pieds de page et les notes « Suite à la page x » ne sont généralement pas considérés comme faisant partie du contenu d'un magazine. Ils font plutôt partie de la présentation de ce dernier ce sont des éléments qui n'ont d'utilité que lorsque le magazine est imprimé. La présentation peut varier suivant le support de publication des informations, mais le contenu reste généralement le même.
Avenue.quark vous permet de séparer le contenu de la présentation en l'extrayant de vos documents QuarkXPress Passport et en le stockant au format XML. Vous pouvez alors réutiliser ce contenu dans des présentations diverses sur papier, Internet, CD-ROM, etc. Il vous suffit d'adapter la présentation à chaque situation.
Qu'est-ce que le langage XML ?
XML signifie « Extensible Markup Language » (Langage extensible de balisage). XML est une façon de présenter la structure du contenu et d'en marquer les éléments de manière significative.
Marquage du contenu
Pourquoi avons-nous besoin de marquer les contenus ? Lorsque nous lisons un magazine, nous savons reconnaître une manchette, mais une telle distinction n'est pas évidente pour un ordinateur. XML vous permet de « baliser » les informations d'une façon compréhensible par les ordinateurs. Une fois que l'ordinateur comprend qu'une ligne est une manchette, il peut automatiquement la formater comme telle.
Pour baliser un contenu en XML, il vous faut insérer une balise XML ouvrante avant le contenu et une balise XML fermante, comme suit :
<manchette>Le rythme de croissance d'Internet est de 400%</manchette>Comme vous l'avez vu, une balise ouvrante consiste en un nom d'élément compris entre deux signes < et >. Une balise fermante est identique mais comporte également un / après le signe <. Dans cet exemple, nous avons balisé le texte « La croissance d'Internet est de 400% » comme manchette en le plaçant entre des balises <manchette> ouvrante et fermante.
Identification d'une structure
Un article comporte généralement une manchette, une signature, un corps de texte et quelques photos ou schémas légendés. Cependant, les ordinateurs ne le savent pas tant que vous ne le leur expliquez pas.
XML vous permet de décrire la structure de vos documents à l'aide de DTD, ou définitions de type de document. La DTD indique que les informations d'un document utiliseront un ensemble de balises particulier et suivront un jeu de règles structurelles précis. Par exemple, la DTD d'un article peut indiquer que :
En appliquant systématiquement les règles d'une DTD, une entreprise peut être assurée que ses documents seront toujours structurés de façon prévisible et cohérente, ce qui facilite grandement le transfert des contenus d'un support à un autre par exemple, de l'impression à Internet, ou vice versa.
Avenue.quark requiert l'utilisation de DTD. Pour des informations concernant la création et l'adaptation de DTD, reportez-vous aux sections « Utilisation des DTD » et « DTD normalisées » dans ce chapitre.
Un format « neutre »
Le langage XML est un format « neutre » car il ne contient aucune information concernant le formatage. Aussi, il peut être utilisé dans un grand nombre d'applications pouvant appliquer différents types de formatage lorsque le contenu est présenté sur des supports variés.
Pour une présentation plus détaillée du langage XML, reportez-vous à la section « Le langage XML » dans ce chapitre.
Que faire d'un contenu stocké au format XML ?
Une fois le contenu du document QuarkXPress Passport extrait, vous pouvez l'utiliser de différentes façons. Par exemple, vous pouvez convertir dynamiquement un contenu balisé en XML au format HTML et le placer sur Internet. Cette conversion d'un contenu QuarkXPress Passport en HTML est plus pratique qu'une simple exportation au format HTML car elle vous permet de formater, reformater et réorganiser facilement le contenu.
Maintenant que vous avez une idée générale de la finalité et du fonctionnement d'avenue.quark, passons aux informations pratiques, en nous intéressant d'abord au langage XML.
Le langage XML (Langage extensible de balisage) permet de spécifier la structure de documents et de marquer des éléments spécifiques de leur contenu à l'aide de balises. Les contrôles structurels d'XML vous assurent que la totalité des éléments nécessaires de ce document est présente dans l'ordre qui convient. Le balisage du contenu facilite son utilisation ou son affichage dans d'autres applications.
Avant de vous parler du fonctionnement d'XML, parlons de son utilité.
Problèmes résolus par XML
XML est dérivé d'un langage de balisage plus ancien et plus compliqué appelé SGML (Langage normalisé de balisage généralisé). Il a été créé pour résoudre un certain nombre de problèmes corrélés, dont certains ont été résolus à l'origine par SGML et d'autres particuliers.
Attribution de structure et de balises à des informations
XML est parfois appelé « métalangage » car il permet d'inventer des langages de balisage adaptés à des usages particuliers. Pour ce faire, il vous faut créer une DTD (définition de type de document). Une DTD indique le type d'informations que peut contenir un document, comment baliser (marquer) ses différentes parties, leur ordre et leur nombre autorisé. Un document est considéré comme « valide » par rapport à une DTD donnée lorsqu'il en respecte les règles.
Les DTD vous permettent de faire respecter la structure des documents. Si vous disposez de la DTD d'un document, vous savez à quel type d'informations vous attendre en l'ouvrant. Les DTD facilitent également le traitement informatique des données de documents XML ; si un ordinateur peut « comprendre » une DTD, il peut « comprendre » les informations de tous les documents respectant ses règles. Par exemple, suivant la DTD d'un document, un programme vous permettra de rechercher chaque occurrence d'un type particulier d'information (tel qu'un nom de société) dans ce document ou de produire une page HTML reprenant toutes les occurrences de ce type d'information (par exemple, une liste de noms de société).
Des DTD spécifiques ont déjà été développées pour la chimie, les mathématiques, la documentation technique et même les oeuvres de fiction. Les applications possibles comprennent la gestion de processus opérationnels, les paramétrages de logiciels et tous les autres domaines nécessitant des échanges d'informations structurées.
Remarque : à l'inverse de SGML, XML vous permet de créer des documents « bien formés » c'est-à-dire, des documents suivant les règles du langage XML, sans respecter de DTD particulière. Il est cependant difficile de maintenir une cohérence entre les documents si vous ne disposez pas d'une norme. C'est pour cela qu'avenue.quark requiert l'utilisation de DTD.
Comprendre le langage HTML
HTML s'est révélé être un format puissant et polyvalent pour l'affichage d'informations sur Internet. Il a toutefois deux défauts principaux : il décrit uniquement le formatage de données et non leur signification, et il est impossible de créer de nouvelles balises HTML.
XML résoud ces deux problèmes. Si vous l'utilisez pour baliser des données dans un document XML, vous pouvez alors baser le formatage HTML sur ces balises. Supposons que votre document XML comporte une liste de sociétés et des renseignements sur chacune. Pour placer cette liste sur une page Internet affichant le nom de chaque société en gras, il vous suffit d'utiliser un convertisseur XML-vers-HTML et de lui donner comme instruction de mettre en gras toutes les lignes associées à une balise <Nomdesociété>. Vous n'aurez plus besoin de parcourir et formater manuellement tous les noms et adresses de sociétés. Le gain de temps pour les concepteurs de sites Internet peut être énorme.
Échange d'informations
Les programmes informatiques ayant été développés par des personnes et des organisations différentes pour des usages divers, les informations y sont stockées dans des formats très variés. Deux sociétés peuvent, par exemple, stocker les informations de clientèle dans deux formats complètement différents, même si ces informations (nom, adresse, numéro de téléphone, etc.) sont essentiellement les mêmes.
XML résout ce problème et fournissant un format normalisé, indépendant pour le transfert d'informations entre applications. XML a été conçu, affiné et approuvé par un groupe de professionnels venant de secteurs différents et travaillant ensemble au sein du World Wide Web Consortium (le W3C). Les spécifications sont disponibles pour tous ceux qui souhaitent les utiliser (consultez le site www.w3.org ou babel.alis.com/web_ml/xml/REC-xml.fr.html) et bon nombre d'organisations et de secteurs s'en servent déjà.
Si deux sociétés décident d'utiliser un logiciel pouvant convertir leurs données au format XML à l'aide d'une DTD commune, elles pourront échanger ces données à volonté, sans risquer d'en perdre à cause de formats incompatibles. Pour plus d'informations concernant les DTD et les échanges d'informations, reportez-vous à la rubrique « DTD normalisées » dans ce chapitre.
Pour une explication plus détaillée du langage XML, reportez-vous à la section « Utilisation du langage XML » dans ce chapitre.
Un document XML contient des données structurées décomposées en « éléments », chacun d'entre eux étant décrit par des balises XML.
Éléments et balises XML
Un élément XML contient un noyau d'informations, telles que le nom de la société, une manchette ou un numéro de pièce. Vous créez un élément en plaçant une information entre deux balises XML : une balise ouvrante contenant le nom de l'élément entre un signe « inférieur à » et un signe « supérieur à », et une balise fermante identique, mise à part la barre oblique (/) précédant le nom de l'élément. Par exemple, un élément balisé « nom » se présentera comme suit :
<nom>Gérald</nom>Il importe de comprendre la différence entre un élément XML et une balise XML. Une balise XML est simplement l'étiquette collée à une information ; un élément XML comporte à la fois cette information et les balises qui l'entourent.
Les balises XML permettent de décrire et d'ajouter une structure aux données qu'elles entourent. Le paragraphe d'introduction suivant est marqué au moyen d'une balise <introduction> :
<introduction>Dans l'élément <introduction>, vous pouvez baliser d'autres sous-éléments pour structurer davantage votre document :
<introduction>La syntaxe est importante dans les balises XML. Contrairement aux balises HTML, elles distinguent les majuscules et les minuscules ; une balise <Nom> est différente d'une balise <nom>, qui est elle-même différente d'une balise <NOM>. Chaque nom de balise XML doit commencer par une lettre ou un souligné (_) ; les caractères suivants du nom peuvent être des lettres, des soulignés, des nombres, des tirets et des points, mais non des espaces ou des tabulations. Par exemple, le nom de la balise XML <_.dir> est un nom correctement formé, mais les noms <_ dir> et <.dir> ne le sont pas. Le nom de balise <_ dir> est incorrect car il contient un séparateur (une tabulation ou un espace) après le souligné. Le nom de balise <.dir> est incorrect parce qu'il commence par un point au lieu d'un souligné ou d'une lettre.
Il est utile de connaître la différence entre « éléments » et « types d'éléments ». Un type d'élément peut être considéré comme un nom de balise spécifique pouvant être appliqué à des données ; un élément est composé d'une donnée et des balises qui l'entourent. Par exemple, un document contenant une liste de noms et d'adresses peut ne comporter que deux types d'éléments, <nom> et <adresse>, mais des centaines d'éléments utilisant ces balises.
Attributs XML
Supposons que vous travaillez avec des éléments balisés <voiture> et que vous souhaitez indiquer des informations supplémentaires au sujet de chaque élément <voiture> que vous créez. Admettons que vous souhaitez, par exemple, préciser qu'un certain élément <voiture> est une voiture rouge, rapide et chère.
Vous disposez de plusieurs méthodes pour ce faire. Vous pouvez inventer des types d'éléments supplémentaires comme suit :
<voiture>Une autre méthode (plus « propre » peut-être) consiste à utiliser une fonctionnalité XML appelée attributs. Les attributs fournissent des informations sur un élément. Ils sont placés dans la balise ouvrante d'un élément, ainsi aucun doute n'est possible sur l'élément auquel ils sont associés.
Un attribut est composé d'un nom d'attribut suivi d'un signe égal, puis d'une valeur d'attribut placée entre guillemets. L'élément simple suivant utilise trois attributs pour fournir les mêmes informations que dans l'exemple précédent :
<vitesse voiture="rapide" couleur="rouge" prix="cher">Les attributs sont utiles à plusieurs titres. Ils facilitent par exemple les recherches dans un document pour générer une liste de tous les éléments <voiture> contenant la valeur « cher » dans l'attribut de prix. Ils peuvent également être utiles associés à des éléments vides. Pour plus de détails, reportez-vous à la rubrique suivante.
Éléments vides
Les éléments vides comprennent une balise ouvrante et une balise fermante et n'entourent aucune donnée, comme suit :
<numéroidentification></numéroidentification>Du fait que les éléments vides ne comportent aucun contenu entre leurs balises, les balises ouvrante et fermante sont souvent combinées :
<numéroidentification/>Vous pouvez utiliser des attributs avec des éléments vides pour référencer des URL ou des fichiers externes. L'élément vide suivant pourrait être utilisé (à l'aide d'un interprète XML approprié) pour afficher l'image d'une voiture :
<URL imagevoiture="Ferrari1995.jpg"/>Notez que l'ajout d'un attribut nommé « URL » à un élément ne garantit pas l'accès à l'URL lors du traitement du fichier XML. L'application qui traite le fichier doit savoir que faire de l'attribut URL.
Commentaires
Comme avec HTML, vous pouvez inclure des commentaires dans un fichier XML. Ceux-ci sont placés entre <!-- et -->, et sont en fait ignorés par les processeurs XML. Aussi, pour insérer, par exemple, un commentaire à propos du statut d'un élément <adresse>, vous pouvez procéder comme suit :
<Adresse>Instructions de traitement
Dans HTML, les commentaires sont souvent utilisés pour véhiculer des commandes spéciales destinées aux navigateurs et autres processeurs HTML. Afin que les commentaires XML restent de simples commentaires, les auteurs de la spécification XML ont prévu une méthode d'insertion de commandes personnalisées dans des fichiers XML et DTD. Ces commandes personnalisées, appelées instructions de traitement (ou « PI », pour « processing instructions »), sont simplement entourées par <? et ?>. Elles commencent par un nom d'application, suivi d'un espace et de toutes informations pouvant intéresser l'application nommée. Les instructions de traitement peuvent être utilisées partout où les commentaires apparaissent.
Déclaration XML
Chaque document XML peut et devrait commencer par une déclaration XML. Comme une instruction de traitement, la déclaration XML est placée entre <? et ?>. Voici un exemple de déclaration XML :
<?xml version="1.0" standalone="yes"?>L'attribut « version » indique que ce document respecte les règles du programme XML 1.0. L'attribut « autonome » indique que toutes les déclarations de balisage nécessaires au traitement du document XML sont incluses dans ce document.
Références d'entités
Une référence d'entité est un mot représentant un caractère, une chaîne ou un fichier. Par exemple, l'utilisation de la référence d'entité < pour représenter le signe inférieur à (<) dans le contenu d'un document XML permet d'éviter toute confusion de la part de l'analyseur XML (qui interpréterait à tort le signe « < » comme l'ouverture d'une balise). Pour plus d'informations sur les références d'entités, reportez-vous à la rubrique « Références d'entité » de la section « Utilisation des DTD » dans ce chapitre.
XML bien formé
Un document XML bien formé devrait commencer par une déclaration XML et posséder un élément-racine contenant tous les autres éléments (<article> dans l'exemple ci-après). Chaque élément du document doit également comporter une balise fermante correspondante. L'exemple suivant présente un document XML bien formé :
<?xml version="1.0" standalone="yes"?>XML valide
L'utilité d'un document XML bien formé peut être limitée s'il n'est pas également valide. Un document XML est appelé valide s'il respecte une DTD particulière. Pour plus d'informations sur les DTD et la validation des documents XML, reportez-vous à la section « Utilisation des DTD » dans ce chapitre.
Processeurs XML
Les processeurs XML sont simplement des programmes qui lisent et traitent les fichiers XML. Il en existe plusieurs sortes. Certains convertissent les fichiers XML en pages Internet au format HTML ou en fichiers PDF ou PostScript. Ils peuvent également énoncer à haute voix le contenu d'un fichier XML ou le convertir en braille. Ou encore copier des contenus XML structurés dans une base de données.
Analyseurs XML
Un analyseur XML reconnaît les règles XML et vérifie que le document XML est bien formé. Toutefois, un analyseur XML ne vérifie pas nécessairement si un document XML est valide suivant sa DTD ; c'est le rôle d'un analyseur XML de validation (voir ci-dessous).
Analyseurs XML de validation
Les analyseurs XML de validation comparent un document XML à une DTD pour vérifier s'il est conforme aux règles de cette dernière. Un bon analyseur de validation rapportera tous les problèmes rencontrés dans le fichier XML. Pour plus d'informations sur les analyseurs XML, reportez-vous à la section « Utilisation des DTD » dans ce chapitre.
Pour un rappel sommaire des fonctionnalités et des conventions XML, reportez-vous à l'annexe A, « XML Quick Reference », du chapitre 7 « Annexes ».
Une DTD (définition de type de document) spécifie quels éléments un fichier XML peut contenir et la manière dont ces éléments doivent être structurés. Les documents XML ne doivent pas nécessairement avoir une DTD correspondante ; pour autant qu'un fichier XML respecte la syntaxe XML de base, il est considéré comme étant « bien formé » et peut être lu par une application compatible avec le langage XML. Mais seul un fichier XML qui respecte une DTD particulière peut être considéré comme « valide ».
Les DTD sont importantes dans la mesure où elles fournissent une structure fiable, bien étayée pour les documents XML. À défaut de DTD, deux entreprises qui collaborent peuvent décider de structurer et de baliser leurs documents XML de manières totalement différentes ; ainsi leurs stocks de données resteraient incompatibles après qu'elles ont toutes deux fait la transition vers XML. Par contre, si les deux organisations utilisent la même DTD éventuellement une DTD élaborée ensemble, ou une DTD devenue une norme dans leur secteur elles peuvent échanger des informations aisément et de façon prévisible.
DTD externes et internes
On distingue deux types de DTD : les DTD externes et les DTD internes.
D'un point de vue technique, une DTD consiste en une liste de déclarations de balisage (déclarations d'élément, d'attribut, entités, notations, instructions de traitement et commentaires) référencée par une déclaration DOCTYPE. Ce que nous appelons « DTD externes » et « DTD internes » dans ce document ne sont pas techniquement parlant des DTD complètes ; toutefois, elles sont assez fréquemment qualifiées comme telles.
DTD externes
Une DTD externe (ou sous-groupe externe) est un fichier contenant une liste de déclarations de balisage. Les DTD externes peuvent aisément être partagées par différents documents XML et entre organisations. Pour utiliser une DTD externe dans un fichier XML, il vous suffit de la référencer au début du fichier XML, comme suit:
<?xml version="1.0" standalone="no">DTD internes
Une DTD interne (ou sous-groupe interne) est en fait incluse dans le fichier XML qu'elle décrit. Pour utiliser une DTD interne dans un fichier XML, il vous suffit de l'ajouter au début du fichier XML, comme suit :
<?xml version="1.0" standalone="yes">Si le document utilise une DTD externe (ou tout autre type d'entité externe), l'attribut « standalone » (autonome) à la première ligne doit indiqué « no ». Pour plus de détails, reportez-vous à la rubrique « Utilisation des références d'entités » dans cette section.
Combinaison de DTD interne et externe
Dans un document XML donné, vous pouvez préciser une DTD externe, puis compléter ou supplanter cette DTD par une DTD interne. Voici comment se présenterait un tel document XML.
<?xml version="1.0" standalone="no">Planification d'une DTD
Il ne vous suffit pas de vous asseoir et de commencer à rédiger une DTD ; une planification importante s'impose si vous voulez le faire correctement.
Avant d'entamer la procédure de rédaction de votre propre DTD, vous pourriez envisager d'utiliser une DTD normalisée. Pour plus de détails sur cette option, reportez-vous à la section « DTD normalisées » dans ce chapitre.
Commencez par voir ce que vous attendez exactement de votre DTD. Premièrement, pensez aux éléments que vous souhaitez utiliser. Si vous souhaitez utiliser des éléments tels que l'<adresse>, demandez-vous si vous voulez subdiviser ces éléments en sous-éléments tels que <numéro>, <nomDeRue>, <codePostal> et <localité>. (Réfléchissez attentivement à ces subdivisions s'il existe la moindre possibilité que vous transfériez un jour le contenu de vos fichiers XML dans une base de données.)
Jusqu'ici, tout est simple. Ensuite, vous devez imaginer les relations entre tous ces éléments. Une DTD peut préciser quels éléments sont permis, l'ordre qu'ils doivent respecter et quels sous-éléments ils peuvent contenir (en quel nombre). Elle peut spécifier quels autres éléments un élément donné peut contenir, ou encore si un élément donné doit ou non contenir des données.
Eliotte Rusty Harold, dans XML: Extensible Markup Language, recommande d'utiliser un tableau pour vous aider à déterminer les relations entre les divers éléments dans votre DTD. Le tableau devrait reprendre les colonnes suivantes (les données figurant dans les colonnes ne sont fournies qu'à titre indicatif) :
| Nom d'élement | Doit contenir | Peut contenir | Doit être contenu dans |
| <adresse> | <nomDeRue>, <codePostal>, <localité> | <Attention> | <donnéesPersonnelles> |
| <nomDeRue> | <adresse> |
Chaque ligne du tableau devrait représenter un élément que vous souhaitez utiliser dans votre DTD.
Utilisation d'une DTD
Tout comme un fichier XML, une DTD est un simple texte. Un fichier XML peut n'utiliser aucune DTD, utiliser une DTD externe, une DTD interne, ou aussi bien une DTD externe qu'interne.
Quel que soit le type de DTD utilisé par un document XML, celui-ci doit référencer ou inclure la DTD dans son prologue (section de début), directement après la déclaration XML et avant le corps du document XML. La section de la DTD commence par « <!DOCTYPE nomRacine [ » et s'achève par « ]> ». Voici, par exemple, un document XML complet contenant une DTD complète (en gras) :
<?xml version="1.0" standalone="yes">Procédons à un découpage:
Comme vous le voyez, chaque définition de type d'élément précise à la fois le nom de l'élément et le type de données que cet élément peut contenir. Si vous souhaitiez modifier la définition du type d'élément <message> de sorte qu'il ne puisse contenir que du texte et rien que du texte (donc aucun autre élément), vous pourriez changer le mot-clé « ANY » en « (#PCDATA) », comme suit :
<?xml version="1.0" standalone="yes">Mais cela signifierait que l'élément-racine de votre document ne pourrait contenir que des données caractères analysées (voir note ci-dessous) ; vous ne seriez pas en mesure d'ajouter d'autres éléments pour subdiviser l'information.
« PCDATA » signifie « parsed character data » (données caractères analysées), c'est-à-dire du texte qui peut comprendre des références d'entités, des commentaires et des instructions de traitement.
Examinons une DTD plus réaliste. La DTD interne qui suit définit une structure pour un répertoire de filiales :
<!-- L'élément-racine est <répertoireFiliales> -->Remarquez que nous avons inséré un commentaire indiquant que <répertoireFiliales> constituait l'élément-racine de la DTD. Nous l'avons fait car une DTD ne peut désigner explicitement un élément-racine ; préciser l'élément-racine est, techniquement parlant, le rôle de la ligne !DOCTYPE dans un document XML. Mais il est judicieux de préciser les éléments racines à l'aide d'un commentaire, pour que l'utilisateur de la DTD puisse les identifier.
Certaines DTD peuvent contenir plus d'un élément pouvant servir d'élément-racine. Vous pouvez par exemple rédiger une DTD qui contient des définitions servant à la fois aux « White papers » et documents FAQ, et ensuite utiliser cette DTD pour créer les deux sortes de documents en précisant simplement <whitePaper> ou <FAQ> comme élément-racine de chaque fichier XML.
Les autres lignes de la DTD indiquent des éléments relatifs au nom de rue, au code postal, à la localité, (à l'état), au pays, au numéro de téléphone, de fax et à l'adresse e-mail de chaque bureau.
Contrôle de la sélection et de l'ordre des balises
La DTD ci-dessus peut vous satisfaire, mais elle n'utilise pas toutes les caractéristiques du langage XML. Elle ne précise, par exemple, aucun moyen d'indiquer quels éléments d'adresse correspondent à quels bureaux, ni aucun ordre particulier pour les informations. Ainsi, vous pourriez créer un document qui énumère les différentes localités, rues, numéros de téléphone, etc. dans le désordre, tout en étant valide selon cette DTD.
Afin de donner une structure significative à la DTD, vous devez trouver un moyen de lier entre eux tous les éléments constituant chaque énumération et de les placer dans un ordre particulier. Une solution consiste à créer un élément contenant qui rassemblerait les informations pertinentes pour un siège (nous l'appellerons <filiale>) et à préciser ensuite quels sous-éléments doivent composer cet élément contenant et dans quel ordre ils doivent figurer. Tout ceci peut se faire en ajoutant une ligne à la DTD (en gras) :
<!-- L'élément-racine est <répertoireFiliales> -->Selon ce nouvel élément, « si le document contient un élément appelé <filiale>, cet élément doit contenir exactement une donnée pour tous les éléments qui suivent, dans cet ordre, et rien d'autre ».
Que faire si le nom de rue de certaines de vos filiales comporte plus d'une ligne ? Vous pouvez autoriser une ou plusieurs occurrence(s) de chaque élément dans une liste de sous-éléments en ajoutant un + au bout du nom de l'élément. Par exemple, pour autoriser un ou plusieurs éléments <nomDeRue> dans notre élément <filiale>, procédez comme suit :
<!ELEMENT filiale (nomDeRue+, codePostal, localité, pays, téléphone, fax, eMail)>Que faire si certaines de vos filiales n'ont pas de numéro de fax ? Ou en ont plusieurs ? Pour préciser zéro occurrence ou plus d'un élément, faites suivre le nom de l'élément d'un *, comme suit :
<!ELEMENT filiale (nomDeRue+, codePostal, localité, pays, téléphone, fax*, eMail)>Et que faire si certaines de vos filiales se situent dans un pays où les codes postaux n'existent pas ? Pour préciser qu'une occurrence d'un élément donné peut être nulle ou unique, ajoutez un point d'interrogation au bout du nom de l'élément, comme suit:
<!ELEMENT filiale (nomDeRue+, codePostal?, localité, pays, téléphone, fax*, eMail)>Ce que l'on appelle « État » aux États-Unis peut porter un autre nom ailleurs. Le Canada, par exemple, est divisé en provinces. Si vous avez des bureaux tant aux États-Unis qu'au Canada, peut-être souhaiterez-vous avoir la possibilité d'utiliser un élément <état> ou un élément <province>. Pour ce faire, mettez les deux options entre parenthèses, séparées par un caractère | , comme suit:
<!ELEMENT filiale (nomDeRue+, localité, (état|province), codePostal?, pays, téléphone, fax*, eMail)>Enfin, nous pouvons nous assurer qu'un <répertoireFiliales> ne contiendra que des listings de <filiale> en modifiant la définition de <répertoireFiliales> de ANY en (filiale*). Voici notre résultat final :
<!-- L'élément-racine est <répertoireFiliales> -->Pour rappel:
| Symbole | Signification |
| Aucun | Exactement un |
| + | Un ou plus |
| * | Zéro ou plus |
| ? | Zéro ou un |
Les symboles spéciaux peuvent être utilisés en conjonction avec les parenthèses pour créer des déclarations complexes de type d'élément telles que la DTD qui suit, conçue pour énumérer les renseignements relatifs aux contacts sur une base journalière :
<!-- L'élément-racine est <programmeContact> -->Un jour donné, le sujet de cette liste peut être à son bureau, à son domicile ou en déplacement. Ainsi, chaque élément <infoContact> peut comprendre l'une des listes suivantes d'informations, avec les sous-éléments dans l'ordre donné :
Balises vides
Peut-être souhaitez-vous rédiger vos documents XML de telle manière qu'ils puissent être aisément traduits au format HTML. Dans ce cas, il vous faudrait sans doute inclure des balises telles que <BR> et <HR> dans votre fichier XML, en vue de les traduire textuellement dans le fichier HTML.
Vous ne pouvez pas vraiment le faire tel quel en XML, car tout élément doit contenir une balise fermante. Toutefois, vous pouvez créer ce que l'on appelle des balises EMPTY (vides) et laisser au convertisseur XML-vers-HTML le soin de les traduire en balises de sortie adéquates. Pour permettre, par exemple, la création de balises <HR>, vous insérerez la ligne suivante dans la DTD :
<!ELEMENT HR EMPTY>Pour utiliser cette balise, vous pourriez insérer une ligne telle que celle qui suit dans votre fichier XML :
<HR/>Vous ne pouvez l'inclure sous la forme « <HR> », car toute balise XML doit soit contenir une balise fermante, soit se terminer par une barre oblique ; mais un convertisseur XML-vers-HTML devrait convertir le <HR/> en <HR>.
Les balises EMPTY sont souvent utilisées pour contenir des images. L'URL des données de l'image est stockée dans l'un des attributs de la balise EMPTY. Pour plus de détails sur les attributs, reportez-vous à la rubrique « Définition des attributs » dans cette section.
Utilisation de références de caractères
Une référence de caractère est une manière de représenter les caractères Unicode dans les données caractères analysées. La syntaxe des références de caractère est la suivante :
&#ValeurUnicodeDuCaractère;Pour insérer, par exemple, le signe monétaire de l'euro devant le nombre 500 dans un élément <montant>, vous pouvez faire ce qui suit (référence de caractère en gras) :
<montant>€500</montant>Le processeur XML a pour tâche de remplacer les références d'entités de caractère par les caractères Unicode appropriés à la sortie.
Utilisation des références d'entités
Une référence d'entité est un morceau de texte qui représente autre chose, comme un caractère, une chaîne de texte, un fichier XML externe ou un fichier binaire (tel qu'un fichier image ou son). On distingue cinq types de références d'entités :
Ces types de références d'entités sont décrits en détail ci-dessous.
Quelle est la différence entre une entité et une référence d'entité ? Une référence d'entité est la forme abrégée insérée dans un document XML pour représenter une entité. Une entité est le contenu qui remplace la référence d'entité lors du traitement de l'XML.
Références d'entités internes analysées
Une référence d'entité interne analysée est essentiellement une forme abrégée d'une chaîne de caractères que vous comptez réutiliser fréquemment dans un document XML donné. Une référence d'entité interne analysée est déclarée dans le format suivant dans une DTD :
<!ENTITY nomEntité "texteDeRemplacement ">Admettons par exemple que vous construisez un document XML qui contient une liste des employés et quelques informations sur chacun d'entre eux. La fiche de chaque employé doit contenir l'expression « Années d'ancienneté dans la société: », suivie d'un nombre. Plutôt que de sans cesse retaper l'expression manuellement, vous pouvez créer une référence d'entité interne analysée pour cette expression en l'intégrant dans la DTD du document, comme suit :
<!-- L'élément-racine est <listeEmployés> -->Pour utiliser la référence d'entité interne analysée « années » dans le document XML, nous pourrions faire comme suit :
<employé>Lors du traitement de cet élément <employé>, le processeur XML développera la référence d'entité interne analysée, ce qui donnera l'XML suivant :
<employé>Cinq références d'entités internes analysées sont prédéfinies dans XML. À la différence de toutes les autres références d'entités internes analysées, elles font partie des spécifications XML et ne doivent pas être déclarées.
| Caractère | Référence d'entité |
| < | < |
| > | > |
| & | & |
| " | " |
| ' | ' |
Supposons que vous devez utiliser le signe « supérieur à » (>) dans le contenu de votre document XML. Comme vous le savez, le signe « supérieur à » indique la fermeture d'une balise en XML. Afin d'éviter la confusion au processeur XML, vous pouvez remplacer le signe « supérieur à » par « > » à chaque occurrence. Par exemple, pour exprimer « le tout > la somme de ses parties » dans un fichier XML, vous pouvez faire comme suit :
<lieuCommun>Trois restrictions sont formulées à l'utilisation des références d'entités internes analysées :
Références d'entités externes analysées
Une référence d'entité externe analysée vous permet d'inclure un contenu stocké dans un fichier de texte externe. Les références d'entités externes analysées doivent être déclarées dans la DTD de l'une des manières suivantes :
<!ENTITY nomEntité SYSTEM "URL du fichier à référencer">Le premier exemple vous permet d'utiliser l'URL d'un fichier particulier. Le second vous permet d'utiliser le nom d'une ressource, qui peut à son tour indiquer une URL ; l'URL qui suit est une URL « de réserve », à n'utiliser que si le nom est introuvable.
Les références d'entités externes analysées peuvent être utilisées pour partager un contenu entre divers fichiers XML. Voici un exemple de document XML complet dont le contenu est stocké dans un fichier texte appelé "monfichier.txt" sur le site web de Quark™ :
<?xml version="1.0" standalone="no">Cette solution est pratique car elle vous permet d'utiliser également le contenu de « monfichier.txt » dans d'autres fichiers XML.
Si un document utilise des références d'entités externes, l'attribut « standalone » dans la déclaration XML devrait indiquer « non ».
Références d'entités externes non analysées
Que faire pour référencer une image, un tableau, un fichier son, un fichier HTML ou un autre fichier non XML dans un document XML ? Vous ne pouvez pas utiliser de référence d'entité externe analysée, car le processeur XML tenterait d'analyser votre fichier binaire, ce qui engendrerait des erreurs.
Pour contourner ce problème, vous pouvez ajouter une notation à la fin de la référence d'entité externe. Une notation avertit simplement le processeur XML qu'il ne doit pas analyser le fichier cible et indique de quel type de fichier il s'agit. Le format utilisé pour introduire cette notation dans une DTD est le suivant :
<!NOTATION nomNotation SYSTEM "nomApplication">Par exemple, pour établir une connexion entre des fichiers JPEG et Adobe® Photoshop®, vous pourriez ajouter la notation suivante à la DTD :
<!NOTATION jpeg SYSTEM "Adobe Photoshop">Pour utiliser une notation dans une déclaration de référence d'entité externe, utilisez la syntaxe suivante :
<!ENTITY nomEntité SYSTEM "URL" NDATA nomNotation>Par exemple, pour créer une entité intitulée « monImage » qui renvoie à une URL contenant un fichier JPEG, vous pourriez utiliser la balise suivante :
<!ENTITY monImage SYSTEM "http://www.quark.com/image.jpg" NDATA jpeg>Vous pouvez également utiliser la syntaxe PUBLIC avec les notations, en précisant d'abord un nom de notation public et ensuite une URL de notation de réserve :
<!ENTITY monImage PUBLIC "-//Quark//Nom JPEG fictif""http://www.quark.com/xml/image.jpg" NDATA jpeg>Autres manières de référencer des fichiers externes : les références d'entités non analysées ne sont pas la seule manière de référencer des fichiers externes dans des fichiers XML sans préciser qu'ils doivent être analysés. Vous pouvez également stocker l'URL d'un tel fichier en tant que simple contenu d'un élément ou d'un attribut. Le premier exemple ci-dessous référence l'URL d'un fichier image comme contenu d'un élément et le second référence la même URL comme contenu de l'attribut :
À vous de choisir si vous utilisez des entités non analysées, des éléments ou des attributs pour référencer des fichiers non XML. Ces méthodes fonctionnent toutes aussi bien, pour autant que l'application qui traite l'XML sache que les URL sont des URL.
Références d'entités paramétrées internes
Si vous souhaitez créer une référence d'entité utilisée uniquement au sein d'une DTD particulière, vous devez créer une référence d'entité paramétrée. Une référence d'entité paramétrée interne est très similaire à une référence d'entité interne analysée, à la différence près qu'elle commence par % au lieu de &, tant dans la déclaration que lorsqu'elle est utilisée :
<!ENTITY % nomEntité "définition entité">Vous pouvez utiliser les références d'entités paramétrées internes dans un sous-groupe externe de la DTD de la même manière que vous utilisez les entités internes analysées dans un document XML. Par exemple, nous utilisons ici une référence d'entité paramétrée interne pour créer une façon abrégée de faire référence à un modèle de contenu qui décrit le nom d'une personne :
<!ENTITY % nom "(prénom, nom)">Notez que ce genre de référence d'entité paramétrée interne ne peut être utilisée que dans un sous-groupe externe de la DTD.
Références d'entités paramétrées externes
Une référence d'entité paramétrée externe est très similaire à une référence d'entité externe analysée, à la différence près qu'elle commence par % au lieu de &, tant dans la déclaration que lorsqu'elle est utilisée. Par exemple, les deux lignes qui suivent (provenant d'un sous-groupe interne d'un document XML) créent d'abord une référence d'entité renvoyant à une DTD externe appelée « en-têteStandard.dtd » et incluent ensuite cette DTD externe dans le fichier XML :
<!ENTITY % en-têteStandard SYSTEM "en-têteStandard.dtd">Pour plus de détails sur cette utilisation, reportez-vous à la rubrique « Utilisation de DTD publiques » dans cette section.
Les références d'entités paramétrées peuvent être utilisées uniquement dans une DTD.
Les références d'entités paramétrées internes et externes peuvent être combinées. Vous pouvez, par exemple, utiliser des références d'entités paramétrées internes dans le sous-groupe interne pour référencer des entités définies dans le sous-groupe externe. L'avantage est que cela vous permet de modifier la définition d'une entité sans avoir à changer le sous-groupe interne des fichiers XML qui utilisent cette entité. Ainsi, par exemple, vous pourriez insérer la déclaration suivante dans un fichier texte appelé « fichierEntité.txt » :
<!ENTITY % entitéNom "<!ELEMENT nom (prénom, nom)>">Puis, dans le sous-groupe interne des documents XML, ajouter ce qui suit :
<!-- Inclure le fichier contenant l'entité ci-dessus -->>Ceci vous permettrait de changer la définition de la référence d'entité entitéNom dans un nombre indéfini de documents XML simplement en la changeant à l'intérieur du fichier « fichierEntités.txt ».
Définition des attributs
Outre le fait d'avoir un contenu, les éléments peuvent également posséder des attributs (voir la section « Le langage XML » dans ce chapitre). Même si le rôle des attributs ne fait pas l'unanimité, pour les besoins de notre discussion, nous supposerons qu'un attribut doit contenir des informations sur un élément importantes pour un processeur XML, mais ne font pas partie du contenu du fichier XML même.
À titre d'exemple, supposons que vous utilisez XML pour tenir une liste d'ouvrages affichée sur un site Web. La liste peut être affichée de deux manières : intégralement ou en citant tous les ouvrages ajoutés à la liste les 10 derniers jours. Pour ce faire, le document XML doit indiquer la date à laquelle chaque ouvrage est inséré.
Vous pourriez ajouter une sous-balise <dateDentrée> à la définition de la balise <livre>, mais la date à laquelle un ouvrage donné est entré dans votre système ne constitue pas réellement une information sur l'ouvrage même ; aussi, mieux vaut créer un attribut appelé « dateDentrée ».
La syntaxe des déclarations d'attribut est la suivante :
<!ATTLIST nomÉlément nomAttribut typeAttribut valeurParDéfaut>Ainsi, pour donner à l'élément <livre> un attribut « dateDentrée » ayant une valeur par défaut de « 01/01/2000 », nous ajouterons la ligne suivante à la DTD :
<!ATTLIST livre dateDentrée CDATA "01/01/2000">Ensuite, pour utiliser cet attribut dans un élément <livre>, nous utiliserons simplement une paire attribut-valeur, comme suit :
<livre dateDentrée="11/11/1998">Cet attribut fournirait au processeur XML les informations nécessaires pour afficher les ouvrages sur la base de leur date d'entrée.
Attributs requis, implicites et fixes
Chaque attribut peut être requis, implicite ou fixe. Une valeur par défaut d'attribut REQUIRED (requis) stipule que l'élément doit contenir cet attribut. Par exemple, la déclaration d'attribut qui suit précise que chaque élément <livre> doit contenir un attribut « dateDentrée » :
<!ATTLIST livre dateDentrée CDATA #REQUIRED>Une valeur d'attribut IMPLIED (implicite) indique que l'élément peut contenir ou non cet attribut, au gré de l'auteur de l'XML. Par exemple, la déclaration d'attribut suivante stipule que chaque <livre> peut contenir ou non un attribut « dateDentrée » :
<!ATTLIST livre dateDentrée CDATA #IMPLIED>Une valeur d'attribut FIXED (fixe) indique que l'attribut doit contenir une valeur exacte pour chaque élément. Par exemple, la déclaration d'attribut suivante stipule que chaque <livre> doit avoir une « dateDentrée » équivalente à « 11/11/1998 » :
<!ATTLIST livre dateDentrée CDATA #FIXED "11/11/1998">Dans cet exemple, le processeur XML supposera que chaque élément <livre> aura un attribut « dateDentrée » fixé à « 11/11/1998 », même si l'attribut est omis.
Si une déclaration d'attribut a une valeur par défaut, mais ne précise pas #REQUIRED, #IMPLIED ou #FIXED, le processeur XML prend la valeur par défaut comme attribut chaque fois que cet attribut est omis.
Types d'attributs
Le mot-clé CDATA dans notre exemple de déclaration d'attribut indique que nous voulons que cet attribut contienne des données caractères. CDATA n'est toutefois que l'un des types d'attributs possibles. En voici la liste complète.
Un attribut ID doit avoir une valeur par défaut déclarée #IMPLIED ou #REQUIRED. Aucun élément ne peut avoir plus d'un attribut ID.
Aucun élément ne peut avoir plus d'un attribut NOTATION.
Ici, plutôt que de créer un élément à la fois pour les images et les films, nous créons deux éléments distincts, <image> et <film>. Pour chacun de ces éléments, la DTD stipule deux applications différentes qui peuvent être utilisées pour afficher le fichier. Le choix de l'application à utiliser est effectué dans chaque balise <élément> individuelle dans le corps de l'XML.
Attribut xml:lang
L'attribut « xml:lang » vous permet de préciser la langue utilisée dans un élément. Cet attribut devrait contenir l'un des points suivants :
Notez que ces attributs ne sont pas prédéfinis vous devez les déclarer avant de les utiliser.
Pour indiquer la langue souhaitée, mentionnez simplement le code de cette langue. Par exemple, la DTD qui suit contient un élément « xml:lang » et l'élément dans le corps de l'XML spécifie la langue anglaise au moyen de l'ISO 639 :
<!-- Dans la DTD -->Vous pouvez préciser des sous-catégories linguistiques en ajoutant au nom de langue une extension précédée d'un tiret. Par exemple, l'élément qui suit précise l'anglais international (utilisé en Grande-Bretagne), par opposition à l'anglais américain :
<!-- Dans le corps de l'XML -->Attribut xml:space
L'attribut « xml:space » permet d'indiquer à l'application qui traite l'XML qu'elle doit laisser intacts tous les espaces blancs relatifs à un élément et à ses enfants (à moins qu'un des enfants ne réinitialise la balise). Par exemple, la DTD qui suit précise un attribut « xml:space » et l'élément dans le corps de l'XML spécifie « conserver » pour cet élément et ses enfants :
<!-- Dans la DTD -->IGNORE et INCLUDE
Vous pouvez utiliser la balise <![IGNORE[]]> pour demander à l'analyseur XML d'ignorer un extrait de texte dans une DTD externe. Prenons l'exemple suivant :
<-- Cette déclaration d'élément est analysée comme d'habitude: -->Vous pouvez demander à l'analyseur XML d'analyser le texte entre balises en remplaçant simplement IGNORE par INCLUDE, comme suit :
<-- Cette déclaration d'élément est analysée comme d'habitude: -->Utilisation de DTD publiques
Comme signalé plus haut, vous pouvez faire référence à une DTD externe dans la déclaration DOCTYPE d'un document XML, comme suit :
<?xml version="1.0" standalone="no">Si vous utilisez une DTD approuvée par un organisme tel que l'Organisation internationale de normalisation (ISO), vous pouvez utiliser une référence d'entité PUBLIC qui stipule le nom d'un exemplaire de la DTD à la disposition du public. Le cas échéant, vous devez également fournir l'URL d'un fichier DTD SYSTEM, qui servirait au cas où l'exemplaire PUBLIC de la DTD serait indisponible.
<?xml version="1.0" standalone="no">Combinaison de DTD pour créer des DTD complexes
Dans certains cas, vous pouvez créer des DTD distinctes pour définir différentes parties d'un document. Par exemple, votre organisation peut utiliser une DTD pour toutes les informations relatives à l'en-tête et au pied de page de ses fichiers XML, mais des DTD différentes pour le corps des documents rédigés dans diverses divisions de la société. Dans ce cas, il vous suffit de créer une nouvelle DTD unique reprenant les différentes DTD nécessaires et précisant un ordre pour leurs éléments-racines, comme suit :
<!ENTITY % en-têteStandard SYSTEM "en-têteStandard.dtd">Pour les documents créés à l'aide de cette DTD, <QARaptDoc> serait l'élément-racine et <en-têteStandard>, <QARapt> et <piedPageStandard> en seraient les sous-éléments immédiats. Un document utilisant cette DTD pourrait ressembler à ceci :
<?xml version="1.0" standalone="no">Modifications locales apportées aux DTD importées
Dans certains processus opérationnels, les DTD peuvent être quasiment identiques pour une série d'utilisations et n'exigent que des ajustements minimes pour s'appliquer à n'importe quel service ou groupe. La solution est simple : il vous suffit d'insérer la DTD dans la déclaration DOCTYPE, puis d'ajouter toutes les déclarations de balisage nécessaires au sous-groupe interne.
Vous ne pouvez pas redéfinir un élément déjà défini dans la DTD externe, mais vous pouvez redéfinir des entités et des valeurs par défaut pour les attributs.
Validation d'un fichier XML par rapport à une DTD
Si vous rédigez vos documents XML à l'aide d'un traitement de texte, vous pouvez consulter la DTD correspondante et vous assurer que vous en respectez les règles. Mais vous ne serez vraiment certain de l'avoir fait qu'après avoir validé le document XML par rapport à la DTD à l'aide d'un programme appelé analyseur de validation. L'analyseur de validation lit la DTD et contrôle ensuite votre fichier XML pour vérifier s'il en respecte les règles. Un bon analyseur de validation devrait en outre vous signaler les problèmes qu'il décèle (le cas échéant).
Rappelez-vous que si vous voulez contrôler la conformité d'un document XML par rapport à une DTD particulière, vous devez disposer d'un analyseur XML de validation, et non d'un simple analyseur XML. Bon nombre d'analyseurs XML vous diront si un fichier XML est bien formé, mais beaucoup plus rares sont ceux qui vous diront si un fichier XML est valide.
Pour un rappel sommaire des caractéristiques et conventions relatives aux DTD, reportez-vous à l'annexe B, « DTD Quick Reference », du chapitre 7 « Annexes ».
Devez-vous mettre au point une nouvelle DTD, conçue spécialement pour répondre aux besoins de votre organisation ? ou utiliser une DTD normalisée qui vous épargnera le temps d'élaboration et contribuera aux échanges d'informations avec d'autres entreprises de votre secteur ?
Les deux démarches présentent des avantages. Si vous créez votre propre DTD en partant de rien, vous contrôlerez totalement la structure de cette DTD ainsi que sa mise à jour. Toutefois, vous devrez faire face à des investissements considérables en temps et en efforts, et veiller attentivement à prendre en compte les besoins de chaque personne qui utilisera cette DTD. Si vous utilisez une DTD normalisée, vous ne devrez pas procéder à l'élaboration de la DTD, mais devrez respecter les conventions liées à celle-ci et adhérer à la structure qu'elle définit.
Avantages et inconvénients de l'utilisation de DTD normalisées
Si vous prévoyez d'échanger des informations avec d'autres entreprises, il vaudrait mieux utiliser une DTD normalisée. L'utilisation d'une DTD normalisée facilite l'échange et la réutilisation des informations balisées dans d'autres contextes. En effet, c'est l'une des raisons pour lesquelles le langage XML a été mis au point : aider à normaliser les formats de stockage et d'échange d'informations.
Pourtant, l'utilisation d'une DTD normalisée présente des inconvénients particuliers, car deux entreprises peuvent avoir des besoins très différents, même si les données qu'elles manipulent sont essentiellement identiques. Les DTD normalisées peuvent être modifiées pour un usage interne à l'entreprise, ce qui les détourne en partie de leur objectif, qui est d'assurer un format de stockage des informations cohérent entre les entreprises.
Puis-je utiliser une DTD normalisée ?
La possibilité d'utiliser une DTD normalisée dépend d'une série de facteurs.
Existe-t-il une DTD normalisée dans votre secteur d'activité ?
Pour répondre à cette question, vous pouvez consulter les DTD normalisées sur Internet. Deux bonnes adresses à consulter sont www.schema.net et www.xml.org.
Si une DTD normalisée existe, répond-elle à vos besoins ?
Réfléchissez attentivement à ce problème ; si la DTD que vous choisissez ne répond pas à vos besoins, l'effet cumulé de tous les défauts ne fera sans doute que s'aggraver avec le temps.
S'il n'existe encore aucune DTD normalisée pour votre secteur d'activité, y en a-t-il une en cours d'élaboration ?
Extension de DTD normalisées
Certaines entreprises choisissent d'utiliser une DTD normalisée, mais la modifie pour qu'elle réponde à leurs besoins particuliers. Par exemple, afin de pouvoir utiliser la DTD SGML « livre » conforme aux normes ISO, la maison d'édition University of California Press y a apporté une série d'ajustements, ajoutant des éléments pour le stockage des informations telles que les sous-titres et les en-têtes de chapitre. L'ISO indique comment modifier ses DTD de sorte que, même si vous effectuez ces modifications, votre nouvelle DTD reste quelque peu normalisée.
Qu'advient-il si vous devez échanger des données avec d'autres entreprises qui utilisent la DTD originale, non modifiée ? Certaines entreprises optent pour la création d'utilitaires capables de convertir des documents conformes à leur DTD modifiée en documents conformes à la DTD originale. Ce genre de solution vous offre bon nombre des avantages d'une DTD faite sur mesure, tout en vous permettant d'échanger des données avec d'autres entreprises du même secteur d'activité.
Avenue.quark vous permet d'utiliser une DTD pour extraire le contenu structuré des documents QuarkXPress Passport et stocker ce contenu dans le système de fichiers ou dans une base de données. La section qui suit décrit le déroulement du processus à l'aide d'un exemple.
La situation
Supposons que votre entreprise a créé un grand nombre de documents techniques au format QuarkXPress Passport et que vous souhaitez en exporter le contenu au format XML pour le stocker dans une base de données afin de le mettre à la disposition de vos clients sur Internet. Les documents techniques utilisent tous un modèle et des feuilles de style QuarkXPress Passport identiques.
Étape n°1 : Création ou choix d'une DTD
Avant de pouvoir extraire le contenu du document technique dans un format structuré, vous devez disposer d'une structure pour ce contenu. La DTD vous fournit cette structure.
Pour plus de détails sur les DTD, reportez-vous à la section « Utilisation des DTD » dans ce chapitre.
Vous disposez de deux moyens pour vous procurer une DTD à utiliser dans avenue.quark :
Étape n°2 : Création d'un document XML
Créez un nouveau document XML dans avenue.quark et précisez la DTD choisie à la première étape. Tous les éléments obligatoires de la DTD sont automatiquement insérés dans le document XML.
Palette Espace de travail XML pour un nouveau document XML
Étape n°3 : Création d'un jeu de règles de balisage
L'une des particularités d'avenue.quark est le balisage selon des règles. Dans le balisage selon des règles, vous créez une série de règles de balisage qui informent avenue.quark, par exemple, qu'un paragraphe utilisant la feuille de style « manchette » doit généralement être balisé comme <Titre>. Vous pouvez également utiliser les jeux de règles de balisage pour préciser de quelle manière chaque feuille de style de caractères, couleur de texte et style de formatage local doivent être balisés. (Pour plus d'informations sur les jeux de règles de balisage, reportez-vous au chapitre 5, « Jeux de règles de balisage ».)
Étape n°4 : Enregistrement du document XML comme gabarit
Enregistrez le document XML comme gabarit nommé « TechNote.xmt ». Le modèle contient la DTD des documents techniques ainsi que le jeu de règles de balisage que vous avez créé à la troisième étape. Vous pouvez utiliser ce gabarit pour créer autant de fichiers XML de documents techniques que vous souhaitez, sur ce même ordinateur ou sur plusieurs.
Étape n°5 : Ouverture du document QuarkXPress Passport que vous souhaitez baliser
Étape n°6 : Création d'un nouveau document XML basé sur le gabarit XML de document technique
Pour créer un nouveau document XML avenue.quark, la première chose à faire est de choisir dans la liste Gabarit un gabarit sur lequel baser le nouveau document XML. Pour notre exemple, nous utiliserons « TechNote.xmt » de l'étape n°4.
Le gabarit TechNote.xmt facilite le balisage d'une note technique QuarkXPress Passport.
Étape n°7 : Exécution du balisage selon les règles
Pour exécuter le balisage selon les règles, faites glisser le bloc contenant le document technique vers l'élément <TechNote> dans la liste Arbre XML tout en appuyant sur la touche COMMAND (Mac OS) ou Ctrl (Windows). Avenue.quark balise automatiquement le document au moyen du jeu de règles de balisage.
Pour exécuter un balisage selon des règles, faites simplement glisser le bloc vers l'élément approprié de la liste Arbre XML tout en appuyant sur la touche COMMAND (Mac OS) ou Ctrl (Windows). Avenue.quark utilise le jeu de règles de balisage pour baliser la plus grande partie du contenu possible.
Étape n°8 : Exécution de tout le balisage manuel nécessaire
Quelques-uns de vos documents techniques sont prêts après le balisage selon les règles. Pour d'autres, par contre, une partie du contenu devra encore être balisée manuellement ou d'une autre manière. Afin de résoudre ces problèmes, il vous suffit de faire glisser le contenu en question vers l'élément approprié dans la palette Espace de travail XML.
Étape n°9 : Utilisation de votre contenu structuré sur Internet et ailleurs
Dès que le contenu de vos documents techniques est au format XML, divers outils vous permettent de le placer sur Internet. Par exemple, vous pouvez le proposer au format XML pur et simple, à afficher au moyen d'un navigateur récent tel que Microsoft Internet Explorer 5.0. Le contenu balisé en XML peut également être utilisé d'une multitude d'autres manières, allant de l'échange électronique d'informations à la création de documents imprimés.